Una de las funcionalidades recomendadas para mejorar el rendimiento en PrestaShop es activar la «cache smarty».
Esta opción la puedes encontrar en «Parámetros avanzados -> Rendimiento», pero no siempre es verdad que lo mejor es tenerla activada.
Existen infinidad de módulos y templates para prestashop y cada uno está programado de mejor o peor manera y a su vez integrado en mejor o peor forma con prestashop, smarty y toda la capa de librerías, apis, hooks y demás historias de un moderno CMS.
El resultado es que muy a menudo se dan «conflictos» y resultados no deseados.
Voy a utilizar como ejemplo el problema encontrado con un ps 1.6 la semana pasada. Un rápido «top» en el sistema mostraba un alto consumo de recursos por parte de los procesos del pool php-fpm. Cada solicitud a ciertas páginas, que no eran siempre las mismas aunque solían ser categorías, dejaba trabajando durante un tiempo indefinido un procesos del pool php y así hasta saturar el pool de procesos php disponibles
Lo primero a verificar cuando un procesos php ocupa demasiado tiempo la cpu es el slow log. En él ya se adivinaba cierto patrón con numerosas referencias a ficheros CacheFs.php, smarty.config.inc.php y… un módulo: blocklayered-ajax.php, aunque los ficheros y funciones no eran siempre las mismas si había ya una pista interesante.
El siguiente análisis que suelo utilizar, cuando no está 100% claro el origen del problema, es ver los «system calls» que realizan los procesos en ejecución. Para ello un simple y útil strace con el pid del proceso en cuestión rápidamente me dio la pista definitiva. Se apreciaba un «bucle» aparentemente infinito en llamadas de este tipo:
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084/2/1/7", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084/2/1", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084/2", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory", {st_mode=S_IFDIR|0771, st_size=1929, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache", {st_mode=S_IFDIR|0771, st_size=12, ...}) = 0
lstat("/home/..../www/..../cache/smarty", {st_mode=S_IFDIR|0771, st_size=4, ...}) = 0
lstat("/home/..../www/..../cache", {st_mode=S_IFDIR|0755, st_size=11, ...}) = 0
lstat("/home/..../www/....", {st_mode=S_IFDIR|0750, st_size=114, ...}) = 0
lstat("/home/..../www", {st_mode=S_IFDIR|0750, st_size=4, ...}) = 0
lstat("/home/....", {st_mode=S_IFDIR|0750, st_size=10, ...}) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=7, ...}) = 0
Sin entrar en el código ni saber realmente el origen del problema (esto ya lo dejo a los desarrolladores) se podía apreciar claramente un problema en la gestión de la cache smarty. Una vez desactivada en el manager de prestashop problema resuelto, no mas procesos php «colgados» ni páginas bloqueadas y el rendimiento del sitio con un TTFB envidiable . Sin ser experto en Prestashop ¿ realmente es útil la cache smarty ?, prestashop implementa otro tipo de cache así que no está muy claro el funcionamiento conjunto de todas ellas.
Comentar que este problema lo he visto en varias ocasiones y si mal no recuerdo, como esta última vez, en prestashops v1.6, aunque es posible que también ocurra en la v1.7 (esta versión ha sufrido grandes cambios respecto a la v1.6).